當我查看 SQL Server 時，我檢查的第一件事是，“相對于我們在此處托管的數據量，這個東西有多少內存？”?長期以來，我一直在使用一些臨時數字，但借助選擇公共數據共享的SQL ConstantCare?用戶的數據，讓我們進行更深入的分析。

我上周四收集了大約 1,400 臺服務器的數據，然后排除了堆疊實例（安裝在同一操作系統上的多個實例）、Azure SQL DB、托管實例和數據少于 10GB 的服務器。

SQL Server 有多少內存？

中值 SQL Server 有 19% 的數據大小作為 RAM。意思是，如果它托管 100GB 的數據，它在服務器中有 19GB 的 RAM。（最大內存大小和文件大小是另一篇博文的討論。）

從該中位數中舉幾個例子：

• 84GB 數據托管在具有 16GB RAM 的 SQL Server 上
• 32GB RAM 托管 166GB 數據
• 55GB RAM 托管 289GB 數據

不過，讓我們以不同的方式對其進行切片：讓我們從這個樣本中取出中值數據量，即 219GB。（如果我按服務器托管的數據量對服務器進行排序，則中間值為 219GB。）在該范圍內的服務器中，一些包括：

• 219GB 數據托管在具有 15GB RAM 的 SQL Server 上（操作系統有 7% 的數據大小）
• 128GB RAM 托管 222GB 數據 (58%)
• 24GB RAM 托管 222GB 數據 (11%)

這些數字發人深省，但在您提出問題之前，請先考慮這一點：數據大小與硬件大小本身并不意味著用戶?滿意。還有很多其他因素在起作用，例如查詢量、調整完成、等待統計信息等。

來自內存與數據大小配置極端的一些示例：

• 4.2TB 數據托管在 16GB RAM 上（哈哈哈）
• 20TB 托管在 64GB 上
• 10GB（不是 TB）托管在 64GB RAM 上
• 61GB 托管在 256GB RAM 上

隨著數據大小的增長，內存不會。

我根據服務器托管的數據大小將服務器分成四分位數：

• 托管 10-59GB 數據的服務器：平均 RAM 大小是數據的 74%！（例如：27GB 數據，20GB RAM）
• 60-224GB 數據：23% RAM 大小（例如：210GB 數據，48GB RAM）
• 225-600GB 數據：13% RAM 大小（例如：488GB 數據，64GB RAM）
• >600GB 數據：6% RAM 大小（例如：2.1TB 數據，128GB RAM）

低端百分比有點傾斜，因為在 10-59GB 層中，操作系統內存意義重大。在我們的 SQL Server 安裝指南中，我們告訴人們至少為操作系統留出 4GB，我認為大多數系統管理員會認為 2GB 是最低限度。但是，隨著數據的增長，百分比下降——這是相當陡峭的。

企業版服務器是否有更多內存？

總體而言，企業版服務器處理大量數據，并且配置了更多內存來處理這些數據：

• 標準版中位數據大小為 168GB，中位 RAM 大小為 32GB
• 企業版：中位數據大小為 358GB，中位 RAM 大小為 54GB
• 開發者版：數據 111GB，RAM 16GB（可憐的開發者）

所以就純粹的服務器大小而言，是的，企業服務器更大，但作為數據的百分比，發生了一些有趣的事情：

• 標準版中位數：RAM 是數據大小的 23%
• 企業版：RAM 是數據大小的 17%
• 開發者版：11%（來吧，伙計，讓他們獲得一些內存！）

較舊的 SQL Server 內存是否更少？

你們都在挨餓恐龍：

• SQL Server 2008 和 2008R2 中位 RAM 是數據庫大小的 15%
• SQL Server 2012：18%
• SQL Server 2014：19%
• SQL Server 2016：22%
• SQL Server 2017：24%

這可能是由于幾個因素造成的，比如不關心舊服務器的性能，或者處理內存容量低得多的舊服務器。

從這往哪兒走

我接下來的想法是：

• 哪些服務器更有可能遇到 PAGEIOLATCH 等待？
• 哪些服務器在查詢工作區內存不足時更有可能遇到 RESOURCE_SEMAPHORE 中毒等待？
• 我可以構建一個基于數據大小預測用戶幸福感的大小調整工具嗎？（意思是，如果你將 3TB 的數據放在 64GB RAM 的虛擬機上，等待統計數據會有多糟糕？）
• 那么，我們可以給客戶同樣的建議嗎？例如，向他們展示他們在數據大小、內存和幸福度方面的排名？